跨境支付正在尝试摆脱银行营业时间的限制。
Swift披露，其共享账本项目17家先行银行中的大多数已开展全天候实时支付交易，涉及欧元、美元、英镑、港元和新加坡元五种货币。
按照Swift公布的技术方案，共享账本可以支持银行在夜间、周末等时段处理跨境付款，但银行之间的最终结算仍通过现有金融基础设施完成。
如果银行间资金尚未完成最终结算，跨境支付为什么能够先行执行？收款人获得资金与银行间最终结算，又有什么区别？
要回答这些问题，需要先了解一笔付款背后的资金流转机制。
客户收到钱，银行之间可能还没结算
假设一家中国企业在周六向新加坡供应商支付一笔美元货款。
付款企业在银行A开立账户，收款企业在银行B开立账户。双方希望当天完成付款，让供应商尽快使用资金。
付款企业通过网银提交指令后，银行A核实账户余额、收款信息及相关交易条件，开始处理付款。
但银行A扣减付款企业的存款，并不会自动增加银行B的资金。
如果付款人与收款人都在银行A开户，这家银行通常可以直接调整内部账户余额。而当资金需要从银行A转至银行B时，就涉及不同银行之间的资金义务。
在跨境支付中，这些义务可能通过代理银行账户、当地支付系统或其他结算基础设施完成。
因此，一笔跨银行付款至少涉及几个需要区分的环节：付款银行接受指令、参与机构确认交易义务、收款银行向客户提供可用资金，以及银行之间最终完成资金清偿。
这些环节的发生时间可能不同。
例如，在相应业务规则和资金保障允许的情况下，银行B可以先向供应商提供可用资金，再按照约定安排银行间最终结算。
对供应商而言，款项已经可以使用；但银行之间可能仍存在待履行的结算义务。
这种安排并非跨境支付独有。
国际清算银行（BIS）2024年发布的《Fast payments: design and adoption》指出，即时支付系统可以让终端用户实时或接近实时地获得资金，而参与支付服务商之间的最终结算不一定同步完成。
不同支付系统可以采用实时全额结算（RTGS），也可以采用延迟净额结算（DNS）。
实时全额结算通常按照单笔交易逐笔完成最终清偿。延迟净额结算则允许参与机构在一定周期内汇总支付义务，计算净额后进行结算。
例如，假设银行A需要向银行B支付100万元，银行B同时需要向银行A支付80万元。在允许双边净额结算的系统中，两家银行可以按照20万元的净额完成相应资金清偿。
这一例子说明，客户之间发生的每笔付款，并不一定要求银行同步完成对应金额的逐笔结算。
不过，具体采用哪种结算方式、客户资金何时可用，都由相应支付系统及参与机构的规则决定。
对于银行来说，如果客户已经获得资金，而相关银行间债务尚未最终清偿，就必须确保后续资金能够按约定到位。
这涉及资金安排和风险管理。
有的支付系统要求参与机构提前准备结算资金，有的采用担保、授信或其他风险控制机制。具体安排取决于支付系统的设计和参与机构之间的约定。
银行需要管理其中的流动性风险和信用风险。
流动性风险主要涉及资金能否在需要的时间和地点及时用于付款。信用风险则涉及相关机构未能履行支付或结算义务时，其他参与方可能承担的损失。
此外，支付系统还需要明确一笔交易什么时候具有结算最终性，即相关资金义务何时按照适用规则得到最终、不可撤销的清偿。
客户资金可用、银行间结算完成以及结算具有最终性，彼此相关，但不能简单视为同一个时点。
跨境支付进一步增加了协调难度。不同国家的结算基础设施可能采用不同的营业时间和运行规则，即使付款指令能够在周末传递，银行仍然需要解决资金可用性和结算安排问题。
如果希望客户随时能够完成跨境付款，参与银行就需要在传统结算系统尚未完成资金清偿时，具备可靠的交易协调和资金保障机制。
Swift共享账本正是从这一环节切入。
Swift共享账本，如何支持全天候支付？
Swift Ledger首先面向银行发行的代币化存款。
代币化存款是以数字代币形式表示的商业银行存款，仍然对应发行银行的存款负债。不同银行发行的代币化存款，即使采用相同货币计价，也分别对应各自的负债和账户体系。
例如，银行A发行的代币化美元存款属于银行A的负债，银行B发行的同类存款则属于银行B的负债。
当银行A的客户需要向银行B的客户付款时，两个银行系统仍然需要确认交易涉及的资金义务，并协调执行和最终结算。
Swift共享账本为参与机构提供了一套共同的交易协调机制。
按照Swift于2026年3月公布的技术方案，共享账本负责记录和验证银行间支付承诺，并同步相关交易状态。银行继续控制自身的资产、资金及结算安排。
其中，资金承诺的验证是理解这套机制的关键。
对于收款银行而言，收到付款请求并不足以保证相关资金最终能够到位。它还需要确认付款银行是否具备相应的资金支持，以及相关支付义务能否按照约定履行。
Swift在技术说明中强调，共享账本通过记录和验证具有资金支持的银行间支付承诺，确保交易执行前具备相应的资金可用性。
这与单纯记录银行愿意付款存在区别。
银行作出支付承诺，意味着其确认相关交易义务；承诺经过验证且具有资金支持，才能为后续执行提供必要的保障。
共享账本将这些承诺及交易状态记录在参与银行可以共同核验的环境中，使相关机构能够依据一致的信息协调支付操作。
回到前面的周末跨境付款场景。
如果银行A和银行B采用Swift Ledger支持的代币化存款支付安排，参与银行可以通过共享账本验证相关资金承诺，并协调交易执行。
在承诺具有资金支持、业务规则及相关条件均得到满足的情况下，银行可以继续处理跨境付款，无须让全部支付操作都等待传统结算系统恢复运行。
不过，银行间确认具有资金支持的承诺，并不等于最终资金结算已经完成。
Swift在3月公布的技术方案中明确，共享账本承担交易流程协调、资金承诺验证和银行间操作同步等职能。参与银行继续管理各自的资金和资产，最终结算通过账本之外的实时全额结算系统、代理银行关系或其他约定机制完成。
这一设计允许支付处理与最终结算采用不同的运行时间安排。
例如，银行可以利用共享账本在周末确认资金承诺、执行相关支付流程，再根据现有结算基础设施的运行安排完成银行间资金清偿。
对参与银行而言，前一个过程解决交易能否继续处理的问题，后一个过程解决相关资金义务如何最终履行的问题。
但两者之间的具体时间关系，仍然取决于实际采用的业务和结算规则。
Swift尚未完整公开所有先行银行的资金保障、授信及结算责任安排，也没有披露每一种试点交易中客户入账与最终结算的全部操作时点。
因此，不能将某一种客户先收款、银行后结算的安排，视为所有Swift Ledger交易的固定流程。
从支付机制来看，共享账本带来的主要变化，是让不同银行能够在同一套交易记录中验证资金承诺、同步执行状态，减少跨机构操作对重复信息核对的依赖。
这种协调能力也与银行流动性管理有关。
传统跨境支付需要银行在不同市场安排资金。由于交易涉及多个机构和结算时区，银行需要及时掌握自身的资金义务，以及相关支付是否已经获得可靠支持。
如果各家银行只能依靠独立系统了解交易状态，信息核对和资金安排就可能更加复杂。
Swift希望通过共享账本提高银行间资金承诺及交易义务的可见度，让参与机构更及时地掌握支付进展，并据此安排流动性。
但共享账本本身并不能消除信用风险和流动性风险。
资金承诺是否获得充分支持、银行在何时需要准备结算资金，以及相关机构无法履约时如何承担责任，仍然需要具体的资金安排、共同规则和风险控制机制支持。
Swift的公开资料能够证明共享账本具备验证资金承诺和协调支付流程的设计能力，但不足以说明全部试点交易采用了相同的资金预存、授信或担保方式。
目前，这套机制已经开始接受实际交易检验。
Swift于9月28日披露，17家先行银行中的大多数已经使用共享账本开展全天候实时支付，涉及五种货币，应用场景包括金融机构间结算相关业务、企业资金管理和银行间融资。
这表明，相关技术已经从方案设计进入初步实际应用，但不同银行和业务场景的具体结算安排仍需要根据后续披露判断。
Swift Ledger提供了一种新的跨银行协作方式：通过共享账本验证具有资金支持的交易承诺，让支付处理能够更加灵活地跨越不同市场的营业时间，同时继续使用现有资金和结算基础设施。
对于标题提出的问题，答案也由此清晰。
Swift支持全天候支付，并不意味着银行不再需要最终结算。
客户希望跨境付款能够随时发生，银行则必须确保相应资金义务得到履行。共享账本改善的是支付执行过程中的资金承诺验证和跨机构协调，最终结算仍然需要由参与银行按照相应规则完成。
支付可以越来越快，但资金义务仍然需要可靠地清偿。这也是全天候跨境支付能够持续运行的基础。
这里是支付学院，关注支付，也关注每一次支付产品微小的进化。
来源丨支付之家·支付学院 (观点仅供参考)
未经允许，严禁转载。发布者：支付学院 转载或引用请注明出处：https://www.zfzj.cn/16210.html
