您的支付处理数据模板

ACI Worldwide
您的支付处理数据模板

您的支付处理数据模板

此模板提供了一种结构化的方法来准备您的支付处理 data 以供分析。它概述了需要收集的核心属性、需要追踪的关键活动,以及从系统中提取这些信息的实用指南。遵循这些建议,您可以为识别效率低下环节和优化财务运营奠定坚实的基础。
  • 建议收集的属性
  • 需要追踪的关键活动
  • 针对 ACI Worldwide 的数据提取指南
不熟悉事件日志?了解 如何创建流程挖掘事件日志.

支付处理属性

这些是推荐包含在 event log 中的 data 字段,用于进行全面的支付处理分析。
3 必填 10 推荐 7 可选
名称 描述
事件timestamp
EventTimestamp
活动发生的具体日期和时间。
描述

此属性记录了 ACI 环境中 event 发生的准确时刻。它用于计算所有基于时间的指标,包括周期时间、审批时长和吞吐率。建议使用高精度(毫秒),以便准确排列快速自动步骤的顺序。

为何重要

对于事件排序和计算绩效时长至关重要。

获取方式

咨询交易历史或审计表中的“创建日期”或“更新日期”列。

示例
2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z
支付交易 ID
PaymentTransactionId
ACI 系统中特定支付指令的唯一标识符。
描述

此属性是流程挖掘分析的核心 key,它将与单个支付请求相关的所有 event 联系起来。在 ACI Worldwide 系统(如 MTS 或 UPP)中,这对应于交易进入时分配的唯一参考号。它能够还原从最初请求到验证、审批及最终结算的端到端支付路径。

为何重要

它是将离散事件分组为流程实例所需的基础 Case ID。

获取方式

检查交易表头,在主交易日志中通常标记为 TRN_REF、REFERENCE_NUM 或 UUID。

示例
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
活动名称
ActivityName
支付生命周期中发生的特定步骤或状态变更。
描述

此属性定义了流程图中的 event 节点,例如“支付请求已创建”或“资金已转账”。在 ACI 系统中,这通常源自状态码、审计日志操作类型或 workflow 状态变更。将这些技术状态准确映射为易读的业务活动,对于实现有意义的可视化至关重要。

为何重要

它定义了流程流向,是可视化操作序列的必要条件。

获取方式

源自状态码(如 100=已创建,200=已验证)或审计日志操作列。

示例
支付请求已创建付款已授权付款已结算支付失败
Event User
EventUser
负责该活动的员工 ID 或系统代理。
描述

捕获执行操作的主体——无论是人工用户(如进行审批)还是系统账户(如进行自动结算)。此属性对于“瓶颈分析”至关重要,可识别特定用户或队列是否超负荷。

为何重要

支持资源分析和职责分离审计。

获取方式

交易表中的审计日志或“UpdatedBy”列。

示例
SYSTEM_AGENT_01j.doeapprover_group_a批量处理
付款到期日
PaymentDueDate
若要视为准时,支付必须完成结算的日期。
描述

存储合同规定或请求的执行日期。将此日期与实际结算日期进行对比,以计算“准时支付率”KPI,并为“支付到期日合规”dashboard 提供支持。

为何重要

衡量 SLA 合规性和准时绩效的基准。

获取方式

交易指令,通常为 VALUE_DATE、EXECUTION_DATE 或 DUE_DATE。

示例
2023-11-012023-11-05
付款类型
PaymentType
支付工具的分类。
描述

对支付进行分类(如电汇、ACH、SEPA、RTGS)。不同支付类型的 SLA 和流程往往大不相同。此属性是过滤“端到端支付周期时间”仪表板的主要维度。

为何重要

对于区分高速支付流和批量支付流至关重要。

获取方式

交易抬头,例如 PMT_TYPE、INSTRUMENT_TYPE 或 SERVICE_ID 等字段。

示例
国内电汇国际电汇ACH 贷记即时支付
付款货币
PaymentCurrency
支付金额的 ISO 货币代码。
描述

指定 PaymentAmount 的币种(如 USD、EUR、GBP)。这对于在汇总不同区域业务量的 dashboard 中进行 data 归一化至关重要,有助于理解跨境支付的复杂性。

为何重要

正确解析支付金额所必需的项。

获取方式

交易明细表,通常是 CCY、CURRENCY_CODE 或 ISO_CODE 等字段。

示例
美元EURGBPJPY
处理渠道
ProcessingChannel
发起支付的渠道。
描述

指示支付的入口,如移动端、Web 门户、API 或文件上传。这有助于进行“支付流程变体分析”,查看某些渠道是否比其他渠道更容易出现错误或延迟。

为何重要

按输入方式细分绩效。

获取方式

交易抬头,通常位于名为 CHANNEL、SOURCE_TYPE 或 INPUT_METHOD 的列中。

示例
SWIFT网银移动应用文件上传
支付金额
PaymentAmount
支付交易的货币价值。
描述

指示转账的财务价值。这是分析“支付吞吐量”和排列瓶颈优先级的关键上下文字段。与低价值的自动化流程相比,高价值支付通常会经历更严格的审批路径(变体分析)。

为何重要

支持按数值细分并计算总处理量。

获取方式

交易明细表,通常是 AMT、TRANS_AMOUNT 或 PRINCIPAL_AMOUNT 等字段。

示例
1500.00250000.5050.001000000.00
是否返工
IsRework
指示支付是否经历过重复 Activity 的标志。
描述

数据处理期间计算的布尔标志。如果“支付详情已验证”等 Activity 出现多次或检测到错误循环,则设为 true。该标志用于驱动“支付返工率”KPI。

为何重要

无需复杂的流程查询即可快速识别低效 case。

获取方式

在数据流水线中通过检查每个 Case 的重复 Activity 计算得出。

示例
truefalse
端到端周期时间
EndToEndCycleTime
从请求创建到结算的总时长。
描述

计算“支付请求已创建”与“支付已结算”之间的时间差。这是“平均支付交易周期时间”KPI 和整体效率分析的核心指标。

为何重要

衡量流程速度的核心指标。

获取方式

计算方式:Timestamp(Payment Settled) - Timestamp(Payment Request Created)。

示例
2 天 4 小时45分钟12 秒
部门
Department
负责当前活动的内部部门。
描述

EventUser 或队列映射到更广泛的组织单元(如“支付运营”、“合规”、“司库”)。这有助于在“按 Activity 进行的瓶颈分析”中查看哪些团队拖慢了流程。

为何重要

按业务职能汇总绩效。

获取方式

源自用户表或组织架构映射。

示例
运营Compliance资金部IT支持
错误代码
ErrorCode
支付失败或需要修复时生成的代码。
描述

捕获“支付失败”或“已识别支付错误”事件的具体原因。在“支付失败与返工分析”仪表板中按此属性分组,可以让业务部门识别最常见的失败根本原因(如“余额不足”、“账户无效”)。

为何重要

对于流程失败的根本原因分析 (Root Cause Analysis) 至关重要。

获取方式

错误日志或状态原因列,通常为 REASON_CODE 或 RETURN_CODE。

示例
R01AM04BE05TECH_ERR_001
最后数据更新
LastDataUpdate
记录最后一次在 data 模型中提取或更新的 timestamp。
描述

追踪分析中所用 data 的新鲜度。这并不代表流程 event 时间,而是 data 摄取的术语时间。它确保分析师了解他们看到的是实时数据还是历史快照。

为何重要

确保数据时效性,帮助识别仪表板中的陈旧数据。

获取方式

执行 ETL 脚本时的系统时间。

示例
2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z
受益人姓名
BeneficiaryName
收款实体名称。
描述

标识交易中的对手方。分析此字段有助于识别与高返工率或延迟相关的特定供应商或客户,支持“支付失败与返工分析”。

为何重要

标识支付目标,对以客户为中心的分析非常有用。

获取方式

支付明细行,例如 CREDITOR_NAME、BENE_NAME 或 PAYEE 等字段。

示例
Acme公司Global Supplies Ltd约翰·史密斯
审批周期时间
ApprovalCycleTime
审批阶段耗时。
描述

计算从“支付已送审”到“支付已批准”(或已拒绝)之间的时间。该指标会输入到“支付审批周期分析”仪表板中,重点展示人工决策环节的延迟。

为何重要

隔离出流程中依赖人工的部分。

获取方式

计算方式:Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval)。

示例
4 小时15 minutes
对账 ID
ReconciliationId
将支付关联到总账或对账记录的标识符。
描述

当“支付已对账”活动发生时,会填充此 ID。它确保处理引擎中的支付与会计系统中的分录相匹配。已结算支付中若缺少此 ID,则表明对账失败。

为何重要

对于“支付对账效率”仪表板至关重要。

获取方式

对账表或特定字段,如 RECON_REF 或 GL_REF。

示例
REC-9921GL-Entry-2023-11
支付是否逾期
IsPaymentLate
指示支付是否在截止日期后结算的标志。
描述

一个布尔标志,用于比较实际结算日期与 PaymentDueDate。用于计算仪表板中的“支付截止日期合规性”指标并识别 SLA 违规。

为何重要

简化合规报告流程。

获取方式

计算方式:SettlementDate > PaymentDueDate。

示例
truefalse
源系统
SourceSystem
event data 来源系统的名称。
描述

标识 ACI Worldwide 生态系统中的特定应用或模块(如 ACI MTS、ACI UPF)或流程中涉及的外部系统。这在跨多个账本缝合数据或支付涉及外部清算中心时尤为重要。

为何重要

提供 data 提取来源的背景信息,有助于调试 data 血缘关系。

获取方式

提取期间硬编码,或在存在多个实例时从 SystemID 列衍生。

示例
ACI MTSACI UPPSAP GLSwift 网关
起始地区
OriginatingRegion
发起支付请求的地理区域。
描述

指示请求者的物理或逻辑位置。这有助于“支付流程变体分析”,了解特定地区是否遵循非标准路径或经历更高的拒绝率。

为何重要

为流程绩效提供地理维度背景。

获取方式

交易抬头,通常源自网点代码或国家代码。

示例
北美欧洲、中东和非洲亚太
必填 推荐 可选

支付处理活动

这些是在 event log 中需要捕获的关键流程步骤和里程碑,以便在支付处理中进行准确的流程发现。
6 推荐 8 可选
活动 描述
付款已批准
一个关键里程碑,指授权用户批准支付,允许其进入执行阶段。这通常在审批人在系统用户界面执行操作时,作为显式事件被捕获。
为何重要

此活动是一个主要检查点,且往往是严重的瓶颈。分析该步骤前的等待时间以及审批周期的时长,有助于识别加速支付的机会。

获取方式

在审批日志表中查找显式事件,或者在主交易表中查找与特定用户操作和时间戳绑定的“已批准”状态变更。

捕获

在授权用户在系统中完成审批操作时记录。

事件类型 explicit
付款已授权
代表人工审批后的系统级支付授权,包括验证资金或检查反欺诈规则。这可以是显式的日志条目,也可以从表示待执行的状态变更中推断。
为何重要

这是资金发出指令前的关键控制点。此阶段的延迟可能表明系统性能问题,或者合规及反欺诈检查子系统存在问题。

获取方式

在系统处理日志或安全日志中查看显式日志。或者,可以通过状态从“已批准”更新为“已授权支付”来推断。

捕获

支付引擎在通过最终内部检查后记录。

事件类型 explicit
付款已结算
支付流程已完成且资金已记入收款人账户的最终确认,标志着交易结束。这是一个关键 event,代表支付生命周期的成功终点。
为何重要

这是流程的主要成功结束 event。它用于计算整体周期时间和吞吐量,对于几乎所有端到端绩效 dashboard 都至关重要。

获取方式

通常是当收到来自网络的最终结算确认消息,或内部总账更新以反映交易完成时记录的显式 event。

捕获

在收到最终结算文件或消息时记录,状态更新为“已结算”。

事件类型 explicit
支付请求已创建
此活动标志着 ACI Worldwide 系统内新支付交易的启动。它通常是当用户或上游系统提交支付请求时记录的显式 event,同时会创建一个带有唯一 ID 的新交易记录。
为何重要

这是支付流程的主要开始 event。分析从该活动到完成的时间可得出端到端周期时间,这对于衡量整体流程效率至关重要。

获取方式

这很可能是 ACI 核心交易表或专用 event log 中记录的显式 event。请查找与支付交易 ID 关联的创建 timestamp。

捕获

通过创建记录或交易日志中的显式“创建”事件来识别。

事件类型 explicit
支付错误已识别
表示系统在某个阶段检测到支付问题,如无效数据或合规警报。此事件通常会显式记录,并带有相关的错误代码。
为何重要

此活动是所有返工和异常处理分析的起点。它对于“支付失败与返工分析”以及“错误解决周期时间”dashboard 至关重要。

获取方式

在错误日志表中查找显式条目,或在交易表中查找“错误”或“需要更正”的状态变更。这些事件应与支付交易 ID 关联。

捕获

当系统验证或处理引擎标记错误时,会记录一个显式事件。

事件类型 explicit
资金已转账
表示已收到支付网络的确认,资金已成功从付款人账户扣除。这通常是从来自网络的入站状态消息中捕获的。
为何重要

确认外部网络已成功执行支付。这标志着结算期的开始,是“平均支付结算时间”KPI 的关键输入。

获取方式

这是一个由传入的状态更新消息(例如来自 SWIFT 的 MT103 或 ACH 确认)触发的显式 event,用于更新支付记录。

捕获

在收到清算网络的外部确认消息时记录。

事件类型 explicit
付款已对账
代表最后的会计步骤,即将 ACI 中记录的支付交易与银行对账单或分类帐分录进行匹配。这可以是来自对账模块的显式 event,也可以通过状态变更来推断。
为何重要

此活动衡量后台对账流程的效率。此处的延迟可能会影响财务报告的准确性,并掩盖未结算的支付问题。

获取方式

此信息可能来自 ACI 内部的专用对账模块或外部 ERP 系统。它将通过支付记录上“已对账”的状态更新来捕获。

捕获

通过最终的“已对账”状态更新,或通过按支付 ID 联接的对账数据推断。

事件类型 inferred
支付失败
一种终态,表示由于不可恢复的问题导致支付无法完成。这与可解决的错误不同,代表了明确的失败终点状态。
为何重要

追踪此结束 event 对于计算整体支付失败率至关重要。分析失败原因有助于提高 data 质量和优化流程规则。

获取方式

通过交易数据中随后不再变更的最终终态推断,如“失败”、“已取消”或“被银行拒绝”。

捕获

通过支付记录中的终态失败状态推断。

事件类型 inferred
支付已拒绝
当审批人拒绝支付请求时发生,通常需要更正并重新提交。这是一个显式事件,它会中断支付的后续进展并启动返工循环。
为何重要

识别返工和流程低效。追踪拒绝频率有助于诊断初始数据质量或提交政策的问题,支持返工分析。

获取方式

在审批日志中作为显式事件捕获,或在交易表中表现为状态变为“已拒绝”。该事件可能包含拒绝原因代码。

捕获

在审批人在系统中完成拒绝操作时记录。

事件类型 explicit
支付已送审
表示支付已通过初步验证,并已路由至必要的管理或财务审批。这通常通过支付 workflow 内的状态变更来捕获。
为何重要

这标志着审批子流程的开始。衡量从该点到“支付已批准”的时间对于“支付审批周期时间分析”dashboard 至关重要。

获取方式

源自交易数据中支付状态字段的变更,例如变为“待审批”。

捕获

通过状态变更为“待审批”或类似状态以及对应的时间戳推断。

事件类型 inferred
支付指令已发送
标志着支付指令被编译并传输到外部支付网络(如 SWIFT、ACH 或 SEPA)的节点。ACI 系统会显式记录此移交过程,用于审计和追踪。
为何重要

对于许多支付类型来说,这是“无法回头”的关键点。追踪这一点有助于衡量外部依赖项介入之前的内部处理时间。

获取方式

这几乎总是 ACI 交易或消息日志中记录的显式 event,通常包含特定于网络的参考号。

捕获

当支付消息发送到外部网络时,会创建一个显式日志条目。

事件类型 explicit
支付详情已验证
代表自动或手动检查的完成,以确保支付详情(如收款人信息和银行代码)正确。该活动通常通过交易状态从“新建”变为“已验证”或“待审批”来推断。
为何重要

追踪初始 data 验证步骤的效率。此处的延迟可能会造成上游瓶颈,并增加流程后期出现支付错误的可能性。

获取方式

通过主支付交易表中的状态变更字段推断。比较“已创建”状态与随后的“已验证”或类似状态之间的时间戳。

捕获

通过支付状态字段的变更推断,例如从“已录入”变为“已验证”。

事件类型 inferred
支付错误已解决
标志着用户更正了之前识别的错误,并重新提交支付进行处理。这通常在支付状态从错误态变回正常处理态时推断得出。
为何重要

此活动结束了异常循环。从“支付错误已识别”到此 event 之间的时间即为错误解决周期时间,这是衡量运营效率的关键指标。

获取方式

通过状态从“错误”态变更为处理态(如“待审批”或“已验证”)推断。也可以是显式的用户操作日志。

捕获

通过脱离错误状态的状态变更推断,表明已进行更正。

事件类型 inferred
收款已确认
代表内部确认支付已成功处理并已收到确认。这通常作为通知收款人或其他内部系统的触发点。
为何重要

这一里程碑对于衡量截止日期合规性和准时支付率至关重要。它为组织何时认为支付已成功执行提供了一个明确的 timestamp。

获取方式

这通常是在收到外部网络确认后,根据支付交易表中状态变更为“已确认”或“已完成”来推断的。

捕获

通过状态变更为“已确认”或“已处理”推断。

事件类型 inferred
推荐 可选

提取指南

如何从 ACI Worldwide 获取数据