您的支付处理数据模板
您的支付处理数据模板
- 深度交易分析建议属性
- SWIFT 流程的关键活动与里程碑
- 金融数据提取技术指导
付款处理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
事件timestamp
EventTimestamp
|
活动发生的精确日期和时间。 | ||
|
描述
此属性记录事件发生的准确时刻。它用于按时间顺序排列活动,并计算所有基于时长的指标,如前置时间、周期时间和吞吐量。 精确的时间戳对于分析“网络截止时间执行表现”以及识别审批链中的瓶颈至关重要。
为何重要
时间戳是流程挖掘中所有时间分析和性能指标的基础。
获取方式
系统审计日志、报文创建时间戳或数据库交易时间。
示例
2023-10-25T08:30:15Z2023-10-25T14:45:00Z2023-10-26T09:15:22Z
|
|||
|
付款交易 ID
PaymentTransactionId
|
代表端到端付款案例的唯一标识符。 | ||
|
描述
此属性作为流程挖掘的核心案例键 (Case Key)。它将与单笔付款指令相关的所有活动(从最初请求到校验、SWIFT 传输及最终结算)归为一组。在 SWIFT 背景下,这通常映射到交易参考号 (TRN) 或唯一端到端交易参考号 (UETR),以确保跨银行系统的连续性。 它用于重建流程实例路径,对于所有的变体分析和周期时间计算都必不可少。
为何重要
唯一标识是流程挖掘的基础,它能将零散的事件串联成连贯的流程视图。
获取方式
报文报头中的 SWIFT Field 20 (TRN) 或 Field 121 (UETR)。
示例
TRN-20231025-883954392-882-101UETR-9982-1123-5521PAY-US-EU-9912
|
|||
|
最后数据更新
LastDataUpdate
|
记录上次提取或刷新的时间戳。 | ||
|
描述
指示数据最近一次加载到流程挖掘工具的时间。这对于确定数据时效性以及确保仪表板反映付款运营的最新状态至关重要。 它通过提供报告流水线延迟的透明度,增强用户对数据的信任。
为何重要
确保用户了解所呈现数据的时效性和可靠性。
获取方式
ETL 过程执行时间戳。
示例
2023-10-27T12:00:00Z2023-11-01T06:00:00Z
|
|||
|
活动名称
ActivityName
|
发生的流程步骤或事件的名称。 | ||
|
描述
此属性描述了系统日志中记录的特定操作或状态更改。例如:“付款请求已创建”、“通过制裁筛查”或“收到 SWIFT 确认 (ACK)”。 它是流程图的核心维度,定义了可视化图表中的节点,使分析师能够理解对每笔付款执行的操作顺序。
为何重要
它定义了流程中的“具体内容”,从而实现流程流向和变体的可视化。
获取方式
交易日志、审计线索,或源自报文类型(如 MT103 已发送)。
示例
付款请求已创建付款指令已发送收到 SWIFT 确认 (ACK)付款已批准
|
|||
|
源系统
SourceSystem
|
事件数据来源系统的名称。 | ||
|
描述
识别生成事件日志的软件或平台。在付款流程中,这可能是核心银行系统、付款网关或直接是 SWIFT 接口。 此属性有助于验证数据血缘,并在合并来自多个不同银行应用的数据时调试问题。
为何重要
提供数据来源背景,这对于多系统流程挖掘至关重要。
获取方式
在 ETL 期间硬编码或从系统标识符中提取。
示例
SWIFT Alliance Access核心银行系统付款引擎制裁过滤
|
|||
|
SWIFT NAK 代码
SwiftNakCode
|
报文被退回时由 SWIFT 网络返回的错误代码。 | ||
|
描述
包含 SWIFT 网络发出的负面确认 (NAK) 中的特定错误代码(例如 T26, T13)。 此属性驱动“SWIFT 错误与返工分析”仪表板,实现技术故障的分类,以便优先进行系统修复。
为何重要
为网络层面的退单提供技术根因分析。
获取方式
MT 015/019 系统报文,或 ACK/NAK 中的 Field 451。
示例
T26H01T13G02
|
|||
|
SWIFT 报文类型
SwiftMessageType
|
所使用的 SWIFT 报文类型(如 MT103, pacs.008)。 | ||
|
描述
指示付款指令的具体格式。常见类型包括用于客户转账的 MT103 和 pacs.008 等 ISO 20022 等效格式。 用于“付款路径变体分析”,以对比传统 MT 格式与新 ISO 标准的处理效率。
为何重要
区分付款流和处理标准(传统格式 vs. ISO 20022)。
获取方式
SWIFT Block 2(应用报头),报文类型字段。
示例
MT103MT202pacs.008MT101
|
|||
|
UETR
UniqueEndToEndReference
|
用于在 SWIFT gpi 中进行跟踪的唯一端到端交易参考号。 | ||
|
描述
UETR 是一个 36 位的字符串,为整个 SWIFT 网络中的每笔付款提供唯一的、不可更改的参考。与内部 ID 不同,UETR 在各银行间保持一致。 该属性对于实现端到端透明度以及将内部日志与外部 SWIFT gpi 状态更新相关联至关重要。
为何重要
跨不同机构跟踪跨境付款的金标准。
获取方式
SWIFT Block 3, Field 121。
示例
b8c3f4a0-5d2a-4e1b-9c3d-1a2b3c4d5e6f123e4567-e89b-12d3-a456-426614174000
|
|||
|
交易货币
TransactionCurrency
|
代表付款币种的 3 位 ISO 代码。 | ||
|
描述
识别付款所使用的币种(如 USD、EUR、GBP)。由于截止时间因币种而异,这对于“网络截止时间绩效”仪表板至关重要。 它还通过识别跨币种对,支持“货币转换效率”分析。
为何重要
决定路由规则、截止时间和结算通道。
获取方式
SWIFT MT Field 32A (币种) 或 ISO 20022 元素 Ccy。
示例
美元EURGBPJPY
|
|||
|
交易金额
TransactionAmount
|
付款指令的货币金额。 | ||
|
描述
代表转账的主金额。此数据从特定的 SWIFT 字段(如 MT103 中的 Field 32A)中提取。 这对于“高额转账审批周期”仪表板至关重要,它允许按金额大小对付款进行细分,从而分析高风险、高价值交易的审批延迟。
为何重要
支持财务影响分析和按交易规模进行的维度划分。
获取方式
SWIFT MT Field 32A (金额) 或 ISO 20022 元素 IntrBkSttlmAmt。
示例
15000.001250.501000000.0045.00
|
|||
|
受益人 BIC
BeneficiaryBic
|
接收机构的银行识别码 (BIC)。 | ||
|
描述
识别付款的目的银行。这是“受益方拒绝根源”仪表板的关键维度。 通过按受益人 BIC 对失败案例进行分组,银行可以识别出哪些特定的交易对手经常因数据质量问题或特定的格式要求而拒绝指令。
为何重要
对于分析对手方绩效和拒绝模式至关重要。
获取方式
SWIFT Field 57A (代理行) 或 58A (受益机构)。
示例
CITIUS33BARCGB22DRESDEFFHANDSEXX
|
|||
|
处理用户
ProcessingUser
|
执行该活动的内部用户或系统代理。 | ||
|
描述
识别负责该活动的个人或自动化机器人,例如审批制裁命中的合规官,或修复格式错误的业务员。 此属性驱动“验证错误热力图”,让管理层能识别培训需求,或发现与高返工率相关的特定用户。
为何重要
支持资源分析和人工瓶颈识别。
获取方式
系统审计日志,交易表中的“用户 ID”列。
示例
系统J.DoeCompliance_Bot_01M.Smith
|
|||
|
是否 STP
IsStp
|
标记付款是否不需要人工干预。 | ||
|
描述
布尔指标。如果案例中不含“识别到错误”、“付款被拒绝”或人工“修改”活动,则为 True。直接用于计算“直通处理率 (STP)”KPI。 这是付款处理中衡量自动化成功程度的核心指标。
为何重要
衡量流程效率和自动化健康状况的首要指标。
获取方式
根据案例中是否存在特定的负面或人工活动计算得出。
示例
truefalse
|
|||
|
起息日
ValueDate
|
资金供受益人使用的日期。 | ||
|
描述
代表付款报文中指定的结算日期。将此日期与实际的“付款已结算”时间戳进行比较,有助于“结算与对账账龄”仪表板的分析。 它反映了付款的紧急程度,并用于衡量对资金到位相关服务水平协议 (SLA) 的执行情况。
为何重要
对于流动性管理和衡量结算及时性至关重要。
获取方式
SWIFT MT Field 32A (日期子字段) 或 ISO 20022 IntrBkSttlmDt。
示例
2023-10-262023-11-01
|
|||
|
制裁筛查时长
SanctionsScreeningDuration
|
制裁筛查阶段所花费的时间。 | ||
|
描述
计算“付款详情已验证”与“付款已审批”之间的时间差。直接反映在“制裁筛查交付周期”仪表板中。 它能突出显示滞留在合规队列中的特定交易,这些交易会影响整体吞吐量。
为何重要
直接衡量合规效率及其对客户 SLA 的影响。
获取方式
计算特定活动之间的时间戳差值。
示例
1200005003600000
|
|||
|
原产国
OriginatingCountry
|
发起付款实体的国家代码。 | ||
|
描述
指示付款请求发起的司法管辖区。这对于“制裁筛查交付周期”仪表板至关重要,因为来自高风险管辖区的付款通常会经历更严格、更耗时的合规检查。 它支持对付款量和处理延迟进行地理维度分析。
为何重要
合规风险分析和区域绩效的关键维度。
获取方式
衍生自发送方 BIC(国家代码,第 5-6 位字符)。
示例
美国GBDEFR
|
|||
|
拒绝原因
RejectionReason
|
解释付款被退回原因的文本描述。 | ||
|
描述
包含付款失败时的叙述或代码描述,通常见于 SWIFT Field 72(发送者至接收者信息)或退回消息。支持“受益方拒绝根源”分析。 允许分析师进行文本挖掘,找出拒绝原因的共同主题(例如“账号无效”、“受益人姓名不符”)。
为何重要
为流程失败提供定性背景说明。
获取方式
退回报文(MT103 Return)中的 SWIFT Field 72 或 79。
示例
收款人账户已关闭IBAN 无效合规性校验失败银行标识符未知
|
|||
|
指令优先级
InstructionPriority
|
标示付款紧急程度的优先级标志。 | ||
|
描述
衍生自消息头(如“普通”与“紧急”)。这可在“高额转账审批周期”仪表板中进行维度划分,因为紧急付款通常需要加急审批流。 了解优先级分布有助于在高峰时段进行资源规划。
为何重要
有助于区分标准付款与加急付款的 SLA 要求。
获取方式
SWIFT Block 2,报文优先级字段(如 N 代表普通,U 代表紧急)。
示例
普通紧急系统
|
|||
|
是否跨境
IsCrossBorder
|
标记付款是否涉及不同国家。 | ||
|
描述
布尔属性。如果发送方国家与受益人国家不同,则为 True。通过区分国内和国际流,支持“多币种处理延迟”KPI。 跨境付款通常具有更高的复杂性、成本和处理时长。
为何重要
付款复杂度分析的基础维度。
获取方式
发送方 BIC 国家代码与受益方 BIC 国家代码的对比。
示例
truefalse
|
|||
|
符合截止时间
MetCutOffTime
|
标记指令是否在网络截止期限前发出。 | ||
|
描述
布尔标记。通过将“付款指令已发送”时间与特定币种的 SWIFT 网络截止时间对比得出。支持“SWIFT 截止时间遵守率”KPI。 未能在截止时间内完成会导致结算延迟,从而影响流动性头寸。
为何重要
财资与流动性管理的核心运营 KPI。
获取方式
通过将时间戳与静态截止时间参考表对比得出。
示例
truefalse
|
|||
付款处理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
付款已对账
|
将付款交易与往来账 (Nostro/Vostro) 账簿报表进行匹配。当对账系统将交易 ID 关联到报表分录时推断得出。 | ||
|
为何重要
闭合财务环路。此环节的延迟会影响资金可见性和可审计性。
获取方式
对账系统日志或核心银行系统 (CBS) 中的“已匹配”状态。
捕获
比较对账状态
事件类型
inferred
|
|||
|
付款已批准
|
由指定操作员或自动化规则对高额转账执行的最终授权操作。当审批工作流标志设为 true 时明确捕获。 | ||
|
为何重要
“高额转账审批周期”仪表板的关键。识别大额资金调拨在人工签核环节的延迟。
获取方式
审批工作流引擎的审计轨迹。
捕获
执行审批操作时记录
事件类型
explicit
|
|||
|
付款已结算
|
确认资金已存入受益人账户(通常为 gpi 状态 ACSC)。通过 tracker 更新或确认报文明确捕获。 | ||
|
为何重要
代表付款链条在功能上的成功终点。是计算“结算到对账间隙”的关键。
获取方式
SWIFT gpi Tracker (ACSC 状态) 或 MT900/910 确认报文。
捕获
结算确认时记录
事件类型
explicit
|
|||
|
付款指令已发送
|
将格式化后的报文(MT103 或 ISO 20022 pacs.008)传输至 SWIFT 网关。当报文有效负载生成并交付至网络接口时明确捕获。 | ||
|
为何重要
用于计算“SWIFT 截止时间遵循率”。标志着从内部处理到网络处理的过渡。
获取方式
SWIFT Alliance Access (SAA) 日志或网关传输日志。
捕获
消息输出时记录
事件类型
explicit
|
|||
|
付款请求已创建
|
在内部银行系统或 ERP 中初步生成付款指令。当付款单首次分配到唯一的交易参考号(TRN 或 UETR)时明确捕获。 | ||
|
为何重要
确立整个付款生命周期的开始时间。对于计算端到端处理时长以及识别进入 SWIFT 网络前的上游延迟至关重要。
获取方式
核心银行系统 (CBS) 或付款枢纽中的交易表创建时间戳。
捕获
交易记录创建时记录
事件类型
explicit
|
|||
|
通过制裁筛查
|
付款指令成功通过 OFAC/制裁名单筛查流程的时间。从合规系统日志明确捕获,或在“筛查挂起”状态解除时推断得出。 | ||
|
为何重要
对于“制裁筛查交付周期”仪表板至关重要。此处的延迟代表合规瓶颈,而非运营低效。
获取方式
合规过滤系统日志或付款中心合规状态标记。
捕获
筛查状态更新时记录
事件类型
explicit
|
|||
|
付款已划转
|
中间状态更新(通常为 gpi 状态 ACSP),表示付款正在由中间行处理。通过 SWIFT gpi Tracker 更新或状态消息捕获。 | ||
|
为何重要
提供代理行“黑匣子”的透明度。对于分析完整的端到端路径至关重要。
获取方式
SWIFT gpi Tracker 数据源或 MT199/trck 报文。
捕获
收到追踪器更新时记录
事件类型
explicit
|
|||
|
付款被退回
|
收到来自受益行或中间行的退回报文(MT103 Return 或 gpi RJCT 状态)。从传入的 SWIFT 报文中明确捕获。 | ||
|
为何重要
对于“受益方拒绝根源”仪表板至关重要。识别外部阻碍因素,如账号已关闭或路由数据错误。
获取方式
入站 SWIFT 消息(MT103 RET, pacs.004)或 gpi 状态 RJCT。
捕获
收到拒绝消息时记录
事件类型
explicit
|
|||
|
付款详情已校验
|
付款指令成功通过语法和格式检查(如 IBAN 格式、BIC 有效性)。通常在交易状态从“草稿”变为“已校验”或“待授权”时推断得出。 | ||
|
为何重要
此环节的高失败率意味着源头数据质量不佳。用于衡量“验证一次通过率”KPI。
获取方式
付款引擎状态日志或校验历史表。
捕获
比较状态字段的前后变化
事件类型
inferred
|
|||
|
付款错误已解决
|
对之前报错的交易进行成功修改并重新提交。当交易从“修复”队列回到“处理中”或“就绪”状态时推断得出。 | ||
|
为何重要
衡量人工返工团队的效率。此环节耗时过长通常意味着存在培训缺口或错误代码过于复杂。
获取方式
付款枢纽状态日志(显示退出异常队列)。
捕获
对比状态字段退出修复
事件类型
inferred
|
|||
|
发现付款错误
|
因校验失败、NACK 或退回报文而标记交易进行修复的事件。当交易进入“修复”、“更正”或“异常”队列时推断得出。 | ||
|
为何重要
跟踪“错误解决返工率”。此环节发生频率过高会破坏直通率 (STP)。
获取方式
付款枢纽 (Payment Hub) 状态列或异常队列日志。
捕获
对比状态字段与错误/修复状态
事件类型
inferred
|
|||
|
收到 SWIFT 确认 (ACK)
|
收到来自 SWIFT 网络的技术确认 (ACK),证明报文已被接受处理。从网络接口日志中明确捕获。 | ||
|
为何重要
确认消息已成功进入全球网络。区分内部故障与实际的网络传播。
获取方式
SWIFT 网关日志(查找 ACK 与 NACK 信号)。
捕获
收到网络 ACK 时记录
事件类型
explicit
|
|||