お客様の支払い処理データテンプレート
お客様の支払い処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 抽出の手引き
支払い処理アトリビュート
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
発生した特定のプロセスステップ/イベントの名称です。 | ||
|
説明
このフィールドは、「Payment Request Created」や「Payment Settled」など、特定の時点で実行されたアクションを記録します。これはプロセスマップ内のノードを定義し、プロセスフローの構造を決定します。 アナリストは、この属性を使用して操作の順序を理解します。ハッピーパスからの逸脱を特定したり、スキップされたステップを検出したり、複数の承認ループのような冗長なアクティビティを検出したりするために不可欠です。
その重要性
取得元
例
支払い依頼作成済み支払い詳細検証済み支払承認支払決済完了
|
|||
|
イベントのタイムスタンプ
EventTimestamp
|
活動が発生した具体的な日時です。 | ||
|
説明
この属性は、支払いプロセスにおけるすべてのイベントの時間的コンテキストを提供します。システムによってアクションがログに記録された正確な瞬間を記録し、アクティビティを時系列順に並べることができます。 分析では、ステップ間の期間、総サイクルタイム、およびスループットレートを計算するために使用されます。特定のプロセス段階間の遅延を強調することで、ボトルネックの特定を可能にします。
その重要性
このフィールドがなければ時間ベースの分析は不可能です。これは、すべてのパフォーマンスおよび効率に関するKPIを推進します。
取得元
例
2023-10-12T08:30:15Z2023-10-12T09:45:00Z2023-10-13T14:20:10Z
|
|||
|
支払い`トランザクションID`
PaymentTransactionId
|
特定の支払い指示または取引のための一意の識別子です。 | ||
|
説明
この属性は、単一の支払いライフサイクル内のすべてのイベントをリンクするための中央キーとして機能します。これにより、アナリストは初期リクエストから検証、承認、最終決済または照合まで支払いを追跡できます。 分析では、このIDは個別のイベントをプロセスインスタンスにグループ化するために不可欠です。エンドツーエンドのフローの可視化を可能にし、サイクルタイムや手戻りループなど、すべてのケースレベルのメトリックの基礎となります。
その重要性
取得元
例
TRX-2023-899102PAY-US-99281ACH-7721-X99WIRE-2210-001
|
|||
|
ビジネスユニット
BusinessUnit
|
支払いを発生させた社内部門または部署です。 | ||
|
説明
この属性は、支払いを「リテールバンキング」、「商業貸付」、「財務」などの特定の組織単位にマッピングします。 これは、「支払いスループット」や「平均支払いサイクルタイム」などのKPIを部門別に集計するために使用されます。これにより、経営陣が異なる部門間のパフォーマンスを比較し、リソースを効果的に配分するのに役立ちます。
その重要性
取得元
例
財務買掛金リテール業務ウェルスマネジメント
|
|||
|
処理`ユーザー`
ProcessingUser
|
アクティビティを実行したユーザーまたはシステムエージェントの識別子または名前です。 | ||
|
説明
この属性は、誰が、または何がプロセスステップを実行したかを捕捉します。人間オペレーター(例:「J.Smith」)と自動化されたシステムアカウント(例:「SYSTEM_BATCH」)を区別できます。 このデータは、リソース利用状況の分析、手作業によるボトルネックの特定、および職務分掌の監査に使用されます。「処理ユーザー利用率」の計算と、手作業タスクと自動化タスクの区別に役立ちます。
その重要性
取得元
例
jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
|
|||
|
実際の決済`日付`
ActualSettlementDate
|
支払いが実際に最終化され、決済された日付です。 | ||
|
説明
この属性は、資金が移動した、または取引が完了したと見なされる実効日を捕捉します。処理タイムスタンプとは異なり、起算日(バリューデート)を反映します。 分析では、期日と共に使用され、「適時支払い率」を計算します。また、照合フェーズのトリガーでもあり、「支払い照合サイクルタイム」を分析するために不可欠です。
その重要性
支払いの財務的結論を表し、キャッシュ
取得元
例
2023-11-022023-11-14
|
|||
|
支払タイプ
PaymentType
|
支払い方法または手段の分類です。 | ||
|
説明
この属性は、支払いをWire、ACH、SEPA、リアルタイム決済(RTP)、小切手などのタイプに分類します。異なる支払いタイプは、それぞれ異なる処理ルールとSLAに従います。 アナリストは、このフィールドを使用して、異なる決済手段間での「支払い照合サイクルタイム」を比較します。これにより、一部の支払いが即座に決済され、他が日数を要する理由を説明し、パフォーマンスが正しいベンチマークに対して測定されることを保証するのに役立ちます。
その重要性
各タイプが独自の
取得元
例
銀行振込ACH CreditSEPA Instant小切手
|
|||
|
支払期日
PaymentDueDate
|
支払いが決済される予定の日付です。 | ||
|
説明
この属性は、開始者によって要求された、または請求書条件によって定義された支払いの期限を記録します。これは、適時パフォーマンスの目標ベンチマークとして機能します。 このフィールドは、「支払い期日順守」ダッシュボードにとって重要です。この日付を実際の「Payment Settled」日付と比較することで、アナリストは遅延支払いを特定し、潜在的なペナルティを計算し、ベンダー契約への準拠を評価できます。
その重要性
サービス
取得元
例
2023-11-012023-11-15
|
|||
|
支払金額
PaymentAmount
|
支払い取引の金銭的価値です。 | ||
|
説明
この属性は、支払いリクエストに関連する金銭的価値を表します。これは、財務スループットとリスクを分析するための主要なメトリックです。 アナリストは、このフィールドを使用して、高額支払いと低額支払い(多くの場合、異なる承認パスを持つ)でプロセスをセグメント化します。「支払いスループット」ダッシュボードをサポートし、高額支払いがより厳格な審査のためにサイクルタイムが長くなるかどうかを特定するのに役立ちます。
その重要性
取得元
例
1500.00250.501000000.0045.99
|
|||
|
通貨コード
CurrencyCode
|
支払いの通貨を示す3文字のISOコードです。 | ||
|
説明
この属性は、支払い金額の通貨(例:USD、EUR、GBP)を指定します。グローバルな支払いストリームを分析する際に、財務データを正規化するために不可欠です。 分析では、このフィールドにより、通貨別にプロセスパフォーマンスをセグメント化できます。これは多くの場合、異なる決済システムや規制と相関しています。これにより、クロスボーダー決済と国内決済における決済時間の変動を説明するのに役立ちます。
その重要性
複数通貨環境において、財務量を正確に解釈するために不可欠です。
取得元
例
USDEURGBPJPY
|
|||
|
サイクルタイム(日数)
CycleTimeDays
|
リクエスト作成から決済までの日単位の期間です。 | ||
|
説明
この計算された属性は、プロセスのエンドツーエンド時間を測定します。「Payment Settled」と「Payment Request Created」のタイムスタンプ間の差として計算されます。 これは、「平均支払いサイクルタイム」KPIの主要なメトリックです。これを事前に計算しておくことで、パフォーマンス分布分析(例:ヒストグラム)が容易になり、外れ値やトレンドを特定するのに役立ちます。
その重要性
取得元
例
1.50.25.0
|
|||
|
ソースシステム
SourceSystem
|
イベントデータが発生したシステムの名称です。 | ||
|
説明
この属性は、コアバンキングエンジン、決済ゲートウェイ、制裁スクリーニングツールなど、レコードが抽出された特定のソフトウェアコンポーネントまたはデータベースを特定します。 これはデータリネージと検証にとって不可欠です。複数のプラットフォームにまたがるエンドツーエンドのフローを分析する場合、このフィールドは特定の活動がどこで行われたかを区別し、データ品質の問題のトラブルシューティングに役立ちます。
その重要性
特に複数の統合された支払い
取得元
例
FIS OPFTraxPaymentHub_01SanctionsScreeningDB
|
|||
|
最終データ更新
LastDataUpdate
|
レコードが最後に抽出または更新されたタイムスタンプ。 | ||
|
説明
この属性は、分析に使用されるデータの鮮度を示します。これにより、ユーザーはリアルタイムデータを見ているのか、それとも過去の期間のスナップショットを見ているのかを理解するのに役立ちます。 ダッシュボードでは、このフィールドは「データ更新日時」ラベルを表示するためによく使用されます。これにより、最も関連性の高い情報に基づいて意思決定が行われることを保証し、増分データロードの管理に役立ちます。
その重要性
取得元
ETLプロセス メタデータ
例
2023-10-14T00:00:00Z2023-10-15T06:00:00Z
|
|||
|
受取人国
BeneficiaryCountry
|
支払い受取人の国コードです。 | ||
|
説明
この属性は、資金の送付先国を特定します。これは、国内支払いと国際支払いを区別するために使用されます。 このコンテキストは、「支払いコンプライアンス監視」およびルーティング分析にとって非常に重要です。国際支払いは、異なる仲介業者、コンプライアンスチェック、およびより長いサイクルタイムを伴うことが多いため、国別にパフォーマンスを分析することは、これらの変数を分離するのに役立ちます。
その重要性
地理的分析と
取得元
例
USドイツCNGB
|
|||
|
延滞
IsLatePayment
|
支払いが期日後に決済されたかどうかを示す`フラグ`です。 | ||
|
説明
これは計算されたブール属性です。「Payment Settled」日付が「Payment Due Date」よりも遅い場合にtrueを返します。 この属性は、「適時支払い率」KPIの直接的な推進要因です。視覚化レイヤーで複雑な日付ロジックを使用することなく、ユーザーが問題のあるケースを迅速にフィルタリングできるようにすることで、ダッシュボード化を簡素化します。
その重要性
取得元
例
truefalse
|
|||
|
手動`介入`の有無
IsManualIntervention
|
その`アクティビティ`が手動作業を含んでいたかどうかを示す`フラグ`です。 | ||
|
説明
このブール属性は、「Payment Error Resolved」や手動承認など、人間による入力が必要なアクティビティやケースを、ストレートスルー処理(STP)とは対照的にフラグ付けします。 これは「手作業支払い介入率」ダッシュボードにとって不可欠です。完全に自動化されていない支払いの割合を定量化し、デジタルトランスフォーメーションの機会を浮き彫りにするのに役立ちます。
その重要性
自動化された
取得元
例
truefalse
|
|||
|
承認権限
ApprovalAuthority
|
支払いの承認を担当する役割、グループ、または個人です。 | ||
|
説明
この属性は、支払いを承認するためにどの権限レベルまたは特定のユーザーグループが必要かを示し、多くの場合、金額しきい値に基づいています。これにより、承認ワークフローのルーティングを追跡するのに役立ちます。 アナリストは、これを「Payment Authorization Bottlenecks」ダッシュボードをサポートするために使用します。承認時間を権限レベル別に分解することで、特定の管理層が遅延の原因となっているかどうかを確認できます。
その重要性
承認階層の組織分析と
取得元
例
Level 1 ManagerCFO`コンプライアンス``チーム`自動承認`システム`
|
|||
|
支払い`チャネル`
PaymentChannel
|
支払いリクエストが開始されたチャネルです。 | ||
|
説明
この属性は、オンラインバンキング、モバイルアプリ、API、支店など、支払い指示の発生元を記述します。これにより、取引の入力元を理解するのに役立ちます。 アナリストは、これを使用して異なるチャネル間での処理効率を比較します。例えば、API経由で開始された支払いが、支店で手動で入力されたものと比較してエラー率が低いかどうかを判断するのに役立ちます。
その重要性
取得元
例
オンラインバンキングモバイルアプリCorporate GatewayBranch Teller
|
|||
|
検証エラーコード
ValidationErrorCode
|
支払いが検証に失敗した理由を示すコードまたは理由です。 | ||
|
説明
この属性は、支払いが「Payment Error Identified」アクティビティに入ったときに設定されます。これには、「無効なIBAN」、「資金不足」、「受取人住所不明」などの障害に関する詳細が含まれます。 このフィールドは、「支払いデータ検証エラー率」ダッシュボードを推進します。この属性でグループ化することで、手戻りの最も一般的な原因が明らかになり、上流のデータ入力やシステム設定における的を絞った修正が可能になります。
その重要性
取得元
例
ERR-001: Invalid AccountERR-055: Sanctions HitERR-009: Duplicate Transaction
|
|||
|
送信元口座
SenderAccount
|
資金が引き落とされる口座番号です。 | ||
|
説明
この属性は、取引のソースアカウントを特定します。特定の内部口座からの支払いを分析する際に、詳細な粒度を提供します。 分析では、特定の資金調達口座がエラー(例:資金不足)や遅延を起こしやすいかどうかを特定するのに役立ちます。また、台帳エントリをプロセスアクティビティと照合できるようにすることで、照合をサポートします。
その重要性
財務照合と
取得元
例
123456789987654321ACC-TREASURY-01
|
|||
支払い処理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
支払い`インストラクション`送信済み
|
このアクティビティは、FISシステムが最終化された支払い指示をACH、Fedwire、SWIFTなどの関連する決済ネットワークに送信する時点を示します。これは重要なシステム生成イベントです。 | ||
|
その重要性
これは、支払いが内部処理環境を離れたことを示す主要なマイルストーンです。ルーティング効率と外部処理にかかる時間を分析するために不可欠です。
取得元
外部支払い
取得
支払いメッセージが決済ネットワークに送出された際にシステムが生成するイベントです。
イベントタイプ
explicit
|
|||
|
支払い依頼作成済み
|
これは支払いライフサイクルにおける最初のイベントであり、FISシステムで新しい支払い取引が開始された瞬間を表します。通常、ユーザーまたは自動システムが新しい支払いリクエストを提出した際に、取引ログテーブルに明示的なエントリとして捕捉されます。 | ||
|
その重要性
このアクティビティは、プロセスの決定的な開始点として機能します。エンドツーエンドの支払いサイクルタイムを測定し、全体の支払いスループットとボリュームを分析するために不可欠です。
取得元
主要な
取得
新しい支払い
イベントタイプ
explicit
|
|||
|
支払い消込済み
|
これは、支払い取引が銀行明細書または内部台帳エントリと照合される最終会計アクティビティです。これは自動バッチプロセスである場合も、手動ユーザーアクションである場合もあります。 | ||
|
その重要性
このアクティビティは、支払いライフサイクルの最終地点を示します。「支払い照合サイクルタイム」を分析することは、決算プロセスの効率を理解するために非常に重要です。
取得元
支払い
取得
照合
イベントタイプ
inferred
|
|||
|
支払実行許可
|
高額な支払いに対して、または初回承認後に別の権限者による承認が必要となる、最終承認ステップを表します。このアクションは、承認権限を持つユーザーが支払いを確定した際に、明示的なイベントとして捕捉されます。 | ||
|
その重要性
このアクティビティは、「Payment Authorization Bottlenecks」ダッシュボードにとって重要です。「Payment Approved」から分離することで、多段階承認プロセスにおける遅延を特定するのに役立ちます。
取得元
取得
イベントタイプ
explicit
|
|||
|
支払承認
|
承認された`ユーザー`が支払いを承認し、次の`ステージ`に進めることを許可する重要な`マイルストーン`です。これはほとんどの場合、承認者の`ID`とその`ユーザー`が`システム`で`アクション`を実行した`タイムスタンプ`と共に明示的な`イベント`として`ログ`されます。 | ||
|
その重要性
これは、承認サイクルタイムを測定し、財務管理への準拠を確保するための重要なチェックポイントです。この段階での遅延は、適時支払いパフォーマンスに大きく影響する可能性があります。
取得元
承認
取得
承認権限を持つ
イベントタイプ
explicit
|
|||
|
支払決済完了
|
このアクティビティは、資金移動の完了を示し、取引が財務的に決済されたと見なされます。これは通常、支払いネットワークまたはクリアリングハウスから最終決済確認が受領されたときに記録されます。 | ||
|
その重要性
これは、支払いサイクルタイムと適時支払い率を測定するための主要な終点です。コア支払い実行プロセスの成功裡の完了を示します。
取得元
支払い
取得
支払い
イベントタイプ
inferred
|
|||
|
承認のために支払い送付済み
|
検証済みの支払いが承認ワークフローに提出される時点を表します。これは通常、支払いが承認者からのアクションを待っていることを示すステータス変更によって捕捉されます。 | ||
|
その重要性
このアクティビティは、承認サブプロセスの開始を示します。これと「Payment Approved」の間の時間を分析することは、承認ボトルネックを理解するために不可欠です。
取得元
支払い
取得
支払い
イベントタイプ
inferred
|
|||
|
支払い`エラー`発生
|
初期検証後の`プロセス`のある`ポイント`で`エラー`が検出されたことを示します。例えば、受取銀行からの拒否や内部の`コンプライアンス``フラグ`などです。これは、`例外`が発生した際に明示的に`ログ`される`イベント`であることが多いです。 | ||
|
その重要性
このアクティビティは、すべての手戻りおよび例外処理ループの開始点となります。手作業介入率と支払いエラー解決時間KPIの計算に不可欠です。
取得元
取得
支払い
イベントタイプ
explicit
|
|||
|
支払い`エラー`解決済み
|
以前に特定された支払い`エラー`の解決を示し、支払いを再処理または`キャンセル`できるようにします。これは、`例外``ステータス`をクリアするために`ユーザー`が行う明示的な`アクション`です。 | ||
|
その重要性
このアクティビティは、例外処理ループを閉じます。「Error Identified」とこのイベント間の期間は、例外処理における運用効率の主要な指標となります。
取得元
取得
イベントタイプ
explicit
|
|||
|
支払い却下済み
|
このアクティビティは、承認者が支払いリクエストを拒否したときに発生し、通常、修正して再提出するか、完全にキャンセルする必要があります。これは監査目的で記録される明示的なユーザーアクションです。 | ||
|
その重要性
却下を追跡することは、支払い失敗、プロセス逸脱、および手戻りループの一般的な原因を特定するのに役立ちます。また、初期データ品質やコンプライアンスに関する問題を浮き彫りにします。
取得元
承認者が「拒否」
取得
イベントタイプ
explicit
|
|||
|
支払い確認済み
|
支払いが受領されたことを、決済ネットワークまたは受取銀行からの受領確認が届くことを表します。このイベントは、受信するシステムメッセージまたはステータス更新によってトリガーされます。 | ||
|
その重要性
確認は、支払いが
取得元
支払い
取得
イベントタイプ
explicit
|
|||
|
支払い詳細検証済み
|
このアクティビティは、支払いデータがフォーマット、完全性、正確性に関する初期の自動検証チェックを通過したことを示します。これは多くの場合、支払い記録のステータス変更、例えば「New」から「Validated」または「Pending Approval」への変更から推測されます。 | ||
|
その重要性
このアクティビティを追跡することは、データ入力エラーの頻度と場所を特定するのに役立ちます。支払いデータ検証エラー率KPIを分析し、手戻りの原因を理解するための前提条件となります。
取得元
支払い
取得
支払い
イベントタイプ
inferred
|
|||
|
遅延支払いを検知
|
支払いが指定された期日後に決済されたことを示す派生`イベント`です。この`アクティビティ`は明示的に記録されていませんが、二つの`日付``フィールド`を比較することで算出されます。 | ||
|
その重要性
この計算されたアクティビティは、「適時支払い率」KPIと「支払い期日順守」ダッシュボードを直接サポートします。これにより、プロセス遅延がベンダー関係や潜在的な延滞料に与える影響を定量化するのに役立ちます。
取得元
これは直接抽出されるものではありません。データ変換中に、「決済日」タイムスタンプと「支払い期日」フィールドを比較することで計算されます。決済日が期日後である場合、このイベントが生成されます。
取得
「決済
イベントタイプ
calculated
|
|||