10月23日，美国快速支付委员会（U.S. Faster Payments Council，FPC）发布了一份49页的行业指南，专门讨论即时支付中的非资金类消息。
这份名为《Operational Considerations for Non-Value Messages》的指南，由FPC运营考量工作组编制，涵盖付款请求、信息查询、资金退回请求、汇款信息以及系统管理消息等内容。
美国目前拥有两张主要即时支付网络，分别是由The Clearing House运营的RTP和由美联储运营的FedNow。两者都支持全天候即时支付，也都采用ISO 20022消息标准。
但一笔支付从发起到完成，涉及的并不只有资金转移。企业如何向客户发起付款请求？银行怎样查询交易信息？已经完成结算的资金发生误付，又该如何请求退回？
这些操作都离不开非资金类消息。FPC此次发布指南，重点梳理相关消息的业务机制，并比较RTP与FedNow在实际应用中的规则差异。
转账之外，还有哪些支付消息？
在即时支付系统中，直接完成资金转移的消息通常被称为资金类消息（Value Messages）。例如，RTP和FedNow都可以通过ISO 20022标准下的pacs.008消息发起客户信用转账。
非资金类消息（Non-Value Messages）本身不直接完成资金结算，主要用于发起付款请求、查询交易信息、反馈处理状态以及支持异常调查和资金退回。
以企业收款为例，企业可以通过合作金融机构向客户发送付款请求（Request for Payment，RfP），其中包含收款方、金额和付款用途等信息。
请求通过即时支付网络送达付款人的金融机构，再由银行App等渠道展示给客户。客户核对并同意付款后，金融机构才会发起实际的资金转移。
这一过程涉及两类不同的消息。pain.013用于发起付款请求，pain.014用于相关响应，实际付款则需要通过后续资金交易完成。
对于企业而言，付款请求可以与账单管理、应收账款及财务系统连接，减少客户手动填写付款信息的环节。但金融机构也需要核验请求发送方身份、管理发送权限，并防范欺诈者利用虚假付款请求诱导客户转账。
交易发起后，金融机构还可能需要进一步核实相关信息。
例如，一家银行收到付款后，发现交易用途不明确，或者需要补充收付款人资料，可以通过信息查询消息（Request for Information，RFI）向另一家金融机构提出请求。
这类消息可以支持交易调查、反洗钱及制裁筛查等业务，让金融机构围绕具体交易交换信息，减少对电话、电子邮件等人工沟通方式的依赖。
资金退回请求则涉及已经完成的交易。
RTP和FedNow的即时支付交易完成结算后具有最终性。如果付款人误付资金，或者怀疑遭遇欺诈，付款机构不能直接撤销原交易，而是需要向收款机构提出退回请求。
按照FPC指南，付款机构可以通过camt.056发送资金退回请求，收款机构核查后使用camt.029反馈处理结果。即使收款机构同意退回，仍需另行执行实际的资金退回操作。
由此，资金退回形成了请求、调查回应和资金处理等不同环节。银行不仅要处理客户提出的问题，还需要跟踪实际退款结果。
汇款信息同样是即时支付的重要组成部分。
企业收到一笔款项后，需要识别对应的订单、发票或者客户。相关信息既可以包含在资金转移使用的pacs.008消息中，也可以在网络支持的情况下，通过独立的remt.001消息传递更详细的汇款资料。
此外，系统管理消息还承担消息接收确认、处理状态通知等任务，帮助参与机构了解相关业务和技术运行情况。
这些消息分布在付款之前、资金转移过程中及交易完成之后，分别承担业务发起、信息传递和异常处理等任务。
同样采用ISO 20022，两张网络为何还有差异？
虽然RTP和FedNow都采用ISO 20022标准，但在消息支持范围、处理规则和实际运营安排上，两张网络存在不少差异。
以付款请求为例，RTP要求相关发送方按照网络规则完成注册，并通过合作金融机构使用付款请求功能。FedNow则主要由参与金融机构管理相关服务和发送权限。
两张网络都使用pain.013发起付款请求，也都支持pain.014响应消息，但允许的响应状态不同。
FPC指南指出，FedNow支持通过pain.014反馈ACTC（接受）、PRES（已展示）和RJCT（拒绝）等状态，RTP则主要通过这一消息反馈RJCT拒绝状态。
在FedNow中，银行可以通过不同响应状态了解付款请求的处理进展，例如请求是否已向付款人展示、是否被接受。不过，接受付款请求不等于实际资金已经到账，付款仍需通过后续交易完成。
RTP对付款请求的响应方式有所不同。银行通常需要结合后续资金交易及关联信息，判断客户是否完成付款。
交易关联标识也存在区别。
FedNow要求使用端到端标识符（End-to-End ID）关联付款请求与实际支付交易。RTP则允许采用端到端标识符、汇款信息或原始消息标识等不同方式建立关联。
对于同时接入两张网络的银行，这些规则决定了付款请求如何匹配实际交易，以及后台系统怎样跟踪处理结果。
汇款信息方面，两张网络都允许在pacs.008资金转移消息中携带相关内容，但RTP还支持独立的remt.001消息，可以传递更详细的发票级汇款资料。
FedNow不支持这一独立消息类型。
FPC指南同时指出，RTP的remt.001功能并非强制使用，目前采用率较低，尚未得到参与机构的广泛使用。
这对企业自动对账具有实际影响。即使银行接入了RTP，也不能默认交易双方都具备独立汇款消息的收发能力。金融机构需要根据网络支持情况和实际接入能力，安排相应的数据传递与对账流程。
资金退回的处理路径差异更加直接。
按照FPC指南，FedNow可以通过pacs.004消息在网络内执行相应资金退回。
RTP则与参与机构的发送权限有关。具备发送能力的机构，可以通过pacs.008发起反向资金转移。
如果一家RTP参与机构只开通了资金接收功能，实际退回资金时可能需要借助ACH或电汇等其他支付渠道。
这意味着，原始付款虽然通过即时支付网络完成，资金退回却不一定沿用原来的支付渠道。
银行需要将原始交易、退回请求、处理反馈与后续资金记录对应起来，才能确认一笔异常交易最终如何处理。
除了网络规则，FPC还关注金融机构的运营能力。
指南指出，资金退回请求可能涉及运营、反欺诈、资金管理和客户服务等多个团队。一些金融机构仍依赖人工审核、电子邮件或第三方服务商处理相关信息。
即时支付网络全天运行，银行的异常处理流程也需要适应这一特点。尤其在非工作时间，消息能否及时分发、案件由谁接手、处理结果如何反馈，都需要明确的运营安排。
在技术实现上，FPC讨论了核心系统直接处理消息，以及通过支付中台或网关处理消息两种主要模式。
前者可以减少中间处理环节，但需要核心系统适配不同网络的消息规则。后者能够集中处理消息解析、路由及状态管理，并连接银行已有的风控、数字银行等业务系统。
对于同时接入RTP和FedNow的金融机构，如何管理两张网络的消息差异、如何让异常处理流程衔接不同业务系统，都是实际建设中需要解决的问题。
FPC此次发布的49页指南，将这些问题放在非资金类消息的框架下进行集中讨论。
其中，付款请求能否与实际交易准确关联，信息查询能否及时得到回应，以及资金退回涉及不同支付渠道时如何核对结果，都关系到即时支付服务的实际运营。
当资金转移已经能够全天候即时完成，银行还需要保证与交易有关的消息能够被正确处理。特别是在出现误付、欺诈或交易争议时，资金到账之后的处理能力，同样影响整个支付系统的可靠性。
这里是支付学院，关注支付，也关注每一次支付产品微小的进化。
来源丨支付之家·支付学院 (观点仅供参考)
未经允许，严禁转载。发布者：支付学院 转载或引用请注明出处：https://www.zfzj.cn/16166.html
